最近一个需求，你花了多少时间在建模上
回想最近一个涉及算法选择的需求。你是直接开始写代码了，还是先花时间把问题翻译成"输入是什么、输出是什么、约束条件是什么"？
如果直接写了——你在靠直觉编程。直觉有时候对，但建模过程能帮你发现直觉遗漏的约束条件。比如你以为是"找最近的点"，建模后发现需求其实是"找最近的、且满足某些条件的点"。
你能判断手头问题的计算复杂度吗
最近遇到的一个算法问题，你知道它是多项式时间可解的还是 NP-hard 的吗？
不需要严格证明。能说出"这个看起来像旅行商变体，大概率 NP-hard"或者"这就是最短路径，Dijkstra 搞定"就够了。
如果完全没想过复杂度——你可能在无意中尝试精确求解一个没有高效精确解的问题。这种情况下花的时间越多，沉没成本越大。
你写暴力解法了吗
在实现优化算法之前，你写暴力解法了吗？用暴力解法验证过优化版本的正确性了吗？
暴力解法的价值被严重低估。它是正确性的锚——任何优化算法的输出都可以和它对比。如果优化版本给出了不同的结果，要么暴力法有 bug，要么优化法引入了错误。
额外的好处：写暴力解法的过程会强迫你精确定义问题，这本身就是一次建模验证。
你的性能判断是基于理论还是实测
上一次做性能相关的决策，你的依据是大 O 分析还是实际跑的 benchmark？
两个都需要，但优先级不同。大 O 给方向——排除明显不可行的选项。实测给结论——在你的数据、你的硬件、你的场景下，哪个算法实际更快。
如果你只看了大 O 就做决定——O(n log n) 和 O(n) 在 n=1000 时差别可能只有微秒级。常数因子、缓存行为、内存分配模式在这个量级的影响可能比渐近复杂度更大。
你的算法选择文档能让接手者看懂吗
假设你下周休假，有人需要改你选的那个算法。他能在半小时内理解：为什么选这个算法？考虑过哪些替代方案？在什么条件下这个选择不再成立？
如果能——你做了算法决策记录。如果不能——你的选择过程只存在你的脑子里。选择的理由和选择本身一样重要，因为条件变了（数据量增长、性能要求变化、需求调整）的时候，需要知道当初的决策依据还成不成立。